home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2066 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.7 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 26 Jan 1996 19:20:25 +0100
  6. Organization: dis-
  7. Message-ID: <4eb61a$4nd@serpens.rhein.de>
  8. References: <4e0jhq$f0q@sunsystem5.informatik.tu-muenchen.de> <4e114i$4o8@serpens.rhein.de> <4e371l$92b@sunsystem5.informatik.tu-muenchen.de> <4e3jld$la@serpens.rhein.de> <4e5k20$rva@sunsystem5.informatik.tu-muenchen.de> <4e64u7$a2u@serpens.rhein.de> <4e9n67$ron@sunsystem5.informatik.tu-muenchen.de>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) writes:
  12.  
  13. >: Simple and easy: you shouldn't, you mustn't, you can't.
  14.  
  15. >wait a minute, I can't ? So how vlt manages to download on hd
  16. >while I run a editor ? :)
  17.  
  18. You can't in your c0d3rware.
  19.  
  20. >The problem disappears if I also provide selection of the 100% os fallback!
  21.  
  22. So far you don't and you mix c0d3r lore and the use of the system.
  23.  
  24. >mhm haven't you told me native = planar & in chipmem, and isn't chipmem
  25. >something you can blitter around ?
  26.  
  27. Native = planar & chipmem. Doesn't mean that you have a blitter or
  28. even a compatible blitter. Of course up to now this _assumption_
  29. is valid. But what would have been with AAA and an incompatible
  30. blitter ? You would still have chip memory but your blitter code
  31. would break.
  32.  
  33. To check for the blitter you have to check the flags in GfxBase.
  34. You can see wether you have OCS blitter, ECS blitter or AGA blitter.
  35.  
  36. >why is this not your oppinion ? you mean 3 pass is not faster than 4
  37. >pass ? you must be joking.
  38.  
  39. I never said this.
  40.  
  41. >So if user got no AGA or no PAL, he will be happy (?) selecting
  42. >writepixelarray8().
  43.  
  44. He would probably be happier if writepixelarray8 were faster.
  45.  
  46. >: No, you don't read this right. You simply _assume_ that the driver is
  47. >: less than ideal than direct render to vram. This assumption is as
  48.  
  49. >No. I say direct render could be faster.
  50.  
  51. That's not what you said. There is a difference between "could" and
  52. "definitely is".
  53.  
  54. >You said "No", you don't believe
  55. >that there is a case where "direct render can be faster".
  56.  
  57. Rubbish. I believe that there are cases where direct render can be even
  58. slower.
  59.  
  60. >There has been
  61. >code proving you wrong in practice.
  62.  
  63. Can't be because I didn't say this. You are assuming again.
  64.  
  65. >: valid is your other assumption about WaitTOF() to use busy-waiting.
  66.  
  67. >I assume there exist drivers that do this.
  68.  
  69. As most things you say are mere _assumptions_.
  70.  
  71. >you told me.
  72.  
  73. No, I didn't.
  74.  
  75. >you told me
  76. >not to use hi-pri waittof therefore.
  77.  
  78. No, I didn't.
  79.  
  80. >you flame about things you did
  81. >tell.
  82.  
  83. No, I didn't.
  84.  
  85. >: >struct display *getdisplay(320,256,8,MODE_DIRECT_RENDER|MODE_LORES);
  86. >: Sorry, fails.
  87.  
  88. >how you want to know ? you don't know what my function does.
  89.  
  90. It should get you a display where you can poke the bitmap. And sorry,
  91. this wouldn't work everywhere.
  92.  
  93. >"fails." really useful answer...
  94.  
  95. Sure. It tells you that "what a c00l c0d3r assumes to get from an
  96. operating system" is not what he actually gets.
  97.  
  98. >yes, sure. and yes, there are cases wher it is slower.
  99. >conclusion: you get most power is interface can handle both.
  100.  
  101. Always _assuming_ that the programmer supports every possibility.
  102. This is deadly wrong for c0d3rz and is still wrong for OS programmers.
  103.  
  104. >this proves my point that direct render sometimes is faster. TAIC.
  105.  
  106. You didn't claim this. You claimed that it were always faster.
  107.  
  108. >: You said that you need direct rendering to vram _because_ that is
  109. >: faster. And that's wrong.
  110.  
  111. >I need this possibility as there are cases where it is faster.
  112.  
  113. How would you know when it is faster ? Simply assuming that produces
  114. many situations where your code is slower. Using the system might
  115. not give the best speed in a particular setup but it gives the
  116. best speed for all setups.
  117.  
  118. >: I don't care. I might even support this as an unportable exception.
  119. >I know :)
  120.  
  121. You know ? I doubt that. Otherwise you wouldn't accuse me to be
  122. "the last one using WritePixelArray8 in the solar system".
  123.  
  124. >: But more likely I would make the driver API include those higher
  125. >: level functions that would benefit from direct rendering. The user
  126. >: code can then ignore this topic algotether.
  127.  
  128. >what ?
  129.  
  130. I would make the driver API include those higher level functions.
  131. The system could support texture mapping or rendering lots of polygons.
  132.  
  133. >how to direct render if OS doesn't support it ?
  134.  
  135. You don't. The driver does. The driver is allowed to do this.
  136.  
  137. >a hidden hint to bang the hardware by YOU ? ;) can't be ;)
  138.  
  139. No. A couple of line earlier I did such a "hint" but you didn't
  140. understand.
  141.  
  142. >I bet the cheaper ones, the ones only costing as much as 20 A1200,
  143. >got no zoom hardware anyway.
  144.  
  145. AFAIK they still have texture mapping hardware and geometry engines.
  146. Not as fast and powerful as the big machines though.
  147.  
  148. >: Poking hardware isn't efficient from a broader view.
  149. >yep.
  150.  
  151. Then why do you say the opposite all the time ?
  152.  
  153. >: If that produces junk, sure.
  154.  
  155. >On a vanilla A1200 it doesn't ;)
  156.  
  157. Sure it does.
  158.  
  159. >Actually the only thing that can
  160. >make my copper hack crash is - the OS!
  161.  
  162. You are blind. Of course it is _your_ hack that crashes.
  163.  
  164. >If 4.0 will make it crash
  165. >I will ask myself why I didn't overtake the copper with a 080 poke.
  166.  
  167. Or ask yourself why you tried to hack the OS. If you use hacks you
  168. break sooner or later. That's one of the most simple rules.
  169.  
  170. >yep. but not faster than same machine having lores, if blitterdma
  171. >should brake cpu copying to vram.
  172.  
  173. How would you know there was a blitter or something resembling current
  174. Amigas ?
  175.  
  176. >It would be efficient, especially if hardwarezoomers available.
  177.  
  178. It just covers what you need now.
  179.  
  180. -- 
  181.                                 Michael van Elst
  182.  
  183. Internet: mlelstv@serpens.rhein.de
  184.                                 "A potential Snark may lurk in every tree."
  185.